Carlos Garnacho [Tue, 9 Aug 2022 14:00:33 +0000 (16:00 +0200)]
misc: Toggle IBus OSK capability on OSK visibility
Newer versions of IBus (> 1.5.26) have the IBUS_CAP_OSK capability
which can be used to hint the active IM about an OSK driving input as
opposed to a physical keyboard. This may be used by IMs to tweak their
behavior to suit OSKs better.
Add the GNOME Shell side handling for this capability, and toggle it
on whenever the OSK is visible.
Since this is a far too new enum value and we don't want such new
IBus dependency, this change plays fast and loose with JS guarantees,
since a logical OR with an undefined value results in the other operand
unmodified it will work for older versions where the capability does not
exist and thus we want nothing extra enabled.
Alessandro Bono [Mon, 8 Aug 2022 11:33:53 +0000 (13:33 +0200)]
loginDialog: Don't call _loginScreenSessionActivated() when not required
We are calling _loginScreenSessionActivated() even in cases where this is
not required. For example, there are cases where the Active property is
already `true` and properties like `IdleHint`, `IdleSinceHint` and
`IdleSinceHintMonotonic` change. In this cases _loginScreenSessionActivated()
is called and will reset the authPrompt when not necessary.
Daniel van Vugt [Tue, 25 May 2021 09:33:01 +0000 (17:33 +0800)]
st/theme-node-drawing: Conditionally paint the center shadow rectangle
Only when part of it is actually visible.
Because the central rectangle is generally the largest part, this
eliminates most of the shadow's render time. For example, animating
`.workspace-background` by tapping Super, the shell's overall render
time is reduced about 15%.
Daniel van Vugt [Thu, 15 Jul 2021 06:18:48 +0000 (14:18 +0800)]
css: Add a special chroma key color and use it on .workspace-background
There's no visible change here since we're just moving from the
default transparent black to transparent other. But the latter can
be used as a special value to indicate to the rendering code when a
background is expected to be always occluded.
Florian Müllner [Wed, 3 Aug 2022 03:27:44 +0000 (05:27 +0200)]
status/network: Add section classes for each device type
Those will eventually become quick toggles, and as there'll be small
differences like menu headers or which settings panel to launch, it
makes sense to give each its own class.
Florian Müllner [Mon, 1 Aug 2022 14:19:43 +0000 (16:19 +0200)]
status/network: Rename DeviceCategory and base on device type
Right now DeviceCategory is a small section wrapper that shows
a summary instead of its content if it contains too many items.
It will eventually eventually turn into the base class for
network device quick toggles. Who would have thought that
when it was added for the "there's a computer with 32 ethernet
cards" fringe case?!
For now, give it a more appropriate name and use device types
instead of our made-up categories, now that the two map neatly.
Florian Müllner [Mon, 1 Aug 2022 13:13:06 +0000 (15:13 +0200)]
status/network: Give bluetooth its own category
In the quick settings future, each device type will use a separate
toggle. We still have a long way to go, but start with giving
bluetooth its own section/category. Baby steps …
Florian Müllner [Tue, 2 Aug 2022 09:33:37 +0000 (11:33 +0200)]
status/network: Remove status from VPN item
It's odd to swap out a switch with a status label, and the
information isn't that helpful to begin with: It's either
transient (connecting, deactivating, ...), or too little to
be meaningful (unknown, failed, ...).
We're also perfectly happy to not show it in "label mode"
(i.e. when there's just one VPN).
Florian Müllner [Thu, 4 Aug 2022 23:37:56 +0000 (01:37 +0200)]
status/network: Simplify device item labels
Stop providing detailed state descriptions, instead use a name
that best represents the device at the moment (like a wifi SSID,
the carrier name, or the device name as determined by network manager).
Different access points can belong to the same wireless network. As
NetworkManager doesn't handle this for us, we need to track networks
ourselves, and we currently do this using ad-hoc object literals and
monkey-patching.
Clean this up by factoring out a proper WirelessNetwork class, and
associate them to items with a map.
status/network: Use NM utility function for classifying security
Interpreting the different flags is better left to the domain
experts at NetworkManager. It is also much more likely that
NM's own functions will handle newly added flags than our own
code.
status/network: Use connectObject() to connect client signals
We would want the signals to be disconnected if we ever happened to
destroy the indicator. Even if we don't, connectObject() is simply
nicer when connecting half a dozen handlers at once.
There is only one case where we show a notification: When activating
a connection failed.
There is therefore no reason for a generic wrapper around the
notification API. Likewise, tracking the source is a bit pointless,
given that the notification is transient. In fact, as we destroy
an existing notification *before* checking for the source, any
previous source will be gone by that point.
Florian Müllner [Fri, 5 Aug 2022 21:21:21 +0000 (23:21 +0200)]
status/network: Fix error notification for wireguard
The function is a handler for the `notify::state` handler, so
the state and reason parameters used in the checks are always
undefined.
In addition, `DEACTIVATED` is not (just) a failure state. We
clearly don't want to complain about a failed connection when
the change happened on request of the user.
Florian Müllner [Fri, 5 Aug 2022 11:21:26 +0000 (13:21 +0200)]
status/network: Emit 'icon-changed' on primary connection changes
When deciding on whether to show the 'no-route' icon, we check
for the client's connectivity *and* whether the devices's active
connection is used as primary connection.
This is currently masked by the indicator updating the icon on
connection changes anyway, but items should still notify the
change themselves.
Florian Müllner [Mon, 1 Aug 2022 14:55:12 +0000 (16:55 +0200)]
status/network: Catch errors when fetching client
Otherwise any unrelated errors in that function are hidden,
because exceptions in async functions are turned into promise
rejections (and JS cannot know that we won't handle it at a later
point).
Alessandro Bono [Fri, 5 Aug 2022 10:56:04 +0000 (12:56 +0200)]
authPrompt: Don't propagate serviceName to setMessage
There isn't always a serviceName when we set a message. Furthermore we
are passing the serviceName only to decide if we want to wiggle or not.
Pass the wiggle parameters instead. If they are missing, we don't want
to wiggle.
This fixes the following error:
JS ERROR: Exception in callback for signal: login-format-changed: Error: Wrong type number; string expected
setMessage@resource:///org/gnome/shell/gdm/authPrompt.js:542:13
_showRealmLoginHint@resource:///org/gnome/shell/gdm/loginDialog.js:931:26
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47
_updateLoginFormat@resource:///org/gnome/shell/gdm/realmd.js:85:18
_reloadRealm@resource:///org/gnome/shell/gdm/realmd.js:57:14
_onRealmLoaded@resource:///org/gnome/shell/gdm/realmd.js:64:14
_makeProxyWrapper/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:245:34
Now that the old system menu has been ported over, we can move
the power toggle to its intended place. The main difference to
the stand-alone toggle is that the button now uses its natural
size rather than the fixed size of regular quick items.
This port is a bit messier than the previous ones, because the
existing menu section translates less directly to the new UI,
which uses a row of individual toggles for settings, lock and
shutdown.
In order to not complicate the grid layout further by supporting
rows with a different number of columns than the overall grid and
children at their natural size, create a custom, non-reactive
SystemItem item that spans an entire row, and contains the individual
toggles.
This works quite well, even with the shutdown item that uses a menu
for the various actions.
With menu support in place, this is now a straight-forward port:
Just add the existing profiles section to a QuickToggleMenu instead
of a submenu item.
The toggle itself now switches between 'balanced' and the last used
non-default profile.
Between input/output volume and brightness, we have enough use
cases for a common slider QuickSettingsItem, in particular as
the items can have a menu.
Now that the QuickSettingsMenu supports child menus, it is time
to add menu support to quick toggles.
Do that by introducing a QuickSettingsItem parent class with a
construct-only :has-menu property, as that will allow including
menus in items that aren't following the standard icon+label
pattern of QuickToggle (yes, we'll have some of those).
A common parent class also allows us to control the type of
menu that is created. That's important, as we need another
custom menu type to
- constrain the menu's y position to place it underneath
the source actor
- use open/close animations taylored for this use case
quickSettings: Support child menus in QuickSettingsMenu
This is where it gets hairy.
Some quick settings items will have an associated menu. When
opened, the main menu should grow to make room for the child
menu, as it would do if it contained the child.
At the same time, the child menu will attach to its parent, and
block all input there while it is open.
Menu-modal menus so to speak.
Implement this as follows:
- change the QuickSettingsMenu actor to a stack that holds
- the boxpointer (a.k.a. the actual menu)
- an overlay actor to hold child menus
- use constraints to bind the overlay's position and width
to the boxpointer; the y position is offset to align the
overlay with the grid inside the actual menu
- add a placeholder actor to the main grid, whose height is
bound to the overlay height; using a "clone" instead of
the actual overlay means that layout changes are not triggered
from outside the grid hierarchy, which would be prone to
allocation warnings
- update the layout manager to not allocate the placeholder as
a regular grid child, but instead include its height in the
space underneath the row with an open menu
- apply a dim effect to the boxpointer when a child menu is
open, to indicate that input is blocked
WorkspaceBackground's allocate is a hot function called every frame
during overview animations. Port it to C.
While we're at it, cache the work area and the monitor geometry, which
do not need to be re-fetched on every allocation.
This reduces the average WorkspaceBackground allocation time from
0.134 ms to 0.017 ms. With four workspaces, scrolling the overview sees
an average WorkspacesView allocation time improvement from
1.104 ms to 0.678 ms.
The aggregate menu with its submenus isn't well-suited for simple
on-off actions, so we didn't expose the global color-scheme support
that was introduced last cycle.
Quick settings on the other hand are a natural fit for actions like
this, so add a corresponding toggle.
For now, this is another simple toggle. The icon, state and
visibility reflect what the old menu did, and the top bar
icon is still only shown when devices are currently connected.
Night-light is now a simple, always visible toggle that directly
controls the underlying setting. No change to the top bar icon,
which is still only shown while night-light is active (read: at night).
Like the aggregate menu currently, the quick settings menu will
eventually contain some items that should dismiss the menu. And
as those items may appear in child menus or otherwise be nested,
a public method on a global object is more convenient than handing
the main menu down the hierarchy.
The new indicator will eventually expose all the system status
items that are currently provided by the aggregate menu, but in
a more accessible form than the current submenu-heavy menu.
Right now this just adds the new empty indicator to the top bar,
alongside the existing aggregate menu.
This serves the exact same purpose as the existing SystemIndicator
class from PanelMenu, except that it exposes a quickSettingsItems
array instead of a menu.
Most quick settings items are just buttons with icon, label, and
a particular style. While that's easy enough, a dedicated class
with corresponding properties is more convenient.
The quick settings menu is a popover that arranges items in a
reflowing, homogeneous grid. Grid children may span multiple
columns, but not rows.
For now the QuickSettingsMenu that contains the grid is just a
convenience wrapper around the layout manager that does the heavy
lifting. The two will become more intertwined when we add support
for menu toggles though, so the custom menu type is unfortunately
needed.
loginManager: Return objects instead of multiple booleans
Multiple booleans - both in arguments and return values - are almost
always problematic API, because people have to memorize (or more likely
look up) the meaning of each position.
Instead, return a JS object so each value has a name attached to it.
Florian Müllner [Thu, 23 Jun 2022 12:53:29 +0000 (14:53 +0200)]
js: Use async D-Bus wrappers
After porting the more complex cases - in particular those that
affect a module's API - we are left with straight-forward D-Bus
method calls that can be moved to promise-based wrappers in one
go.
For consistency, this also switches from Remote to Async where
the call result is ignored.
Florian Müllner [Thu, 23 Jun 2022 15:02:55 +0000 (17:02 +0200)]
autorunManager: Promisify ContentTypeDiscoverer
Thanks to recent gjs changes - namely the ability to promisify
interface prototypes and promise-based D-Bus wrappers - we can
modernize the ContentTypeDiscoverer API to use an async function
instead of a callback.
Florian Müllner [Thu, 23 Jun 2022 16:13:36 +0000 (18:13 +0200)]
search: Use async functions instead of callbacks
Our search provider API has to be asynchronous to support remote
providers. It doesn't have to be based on callbacks though, now
that async functions provide a nicer alternative.
That is particularly true after gjs's D-Bus wrapper started to
generate promise-based method variants.
projects / gnome-shell.git / log